Business Analyst Community & Resources | Modern Analyst

Three Audacious Goals for Business Analysts in 2013

Jarett Hailes — Wed, 02 Jan 2013 19:07:00 GMT

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals.

Merriam-Webster defines audacious as “intrepidly daring” and “marked by originality”. As the business analysis profession and Business Analyst community continue to mature, more organizations are seeing the value that professionally-executed business analysis can bring. Business Analysts have an opportunity to help organizational leaders achieve their vision for the future. Here are three audacious goals for 2013 to help Business Analysts capitalize on this opportunity.

1. Move Beyond Information Technology Solutions

Most Business Analysts are focused on the development of IT solutions to meet business needs. The ‘IT Business Analyst’ has been hailed as key cog in the overall IT delivery framework for organizations.

While information technology is one crucial supporting function every organization needs, it is not the only area where Business Analysts can deliver value. Technology is only effective if there people who know how to use it and processes that will ensure the overall business is able to perform tasks in an efficient and effective manner. Business Analysts need to ensure that all three of these aspects work together by identifying and assessing requirements for all components, not just the technology-related pieces.

Business Analysts can challenge the perception that their work solely fits into IT by demonstrating their ability to consider the process and people components during their prescribed activities. Go beyond writing system specifications and point out potential challenges that people will have with a complicated screen layout, or identify regulatory or policy issues that will impact certain functional requirements. Such actions will allow clients to see the need for a more holistic approach to solution development and can improve the high failure rates seen by projects that are ostensibly driven by IT. Even if you are working in a systems support role, you have the opportunity to present a more complete picture about proposed modifications that will allow everyone to realize how an application should be changed to meet the organization’s needs.

2. Master and Leverage Complementary Disciplines

As a Business Analyst you already rely on competencies and knowledge from other disciplines. Most business analysis knowledge areas use notions from areas such as systems analysis, project management and facilitation.

There are several disciplines that provide wonderful skills and techniques that Business Analysts can use to help accomplish their daily tasks more effectively. If you take the time to learn and master one or more of these disciplines, your value to your organization can increase exponentially. Not only do you improve your career options but you become a better Business Analyst by being able to deal with a greater breadth of problems.

Some of the disciplines that are worth mastering as a Business Analyst are:

· Change Management: understanding how people deal with change and how to help navigate organizations through change is a crucial set of skills in today’s environment. Business Analysts can leverage change management practices throughout their activities, most noticeably in stakeholder analysis, requirements management, requirements analysis and enterprise analysis.

· Mediation/Conflict Resolution: with change comes the possibility of interpersonal conflicts. People can disagree for a variety of rational and irrational reasons. Business Analysts are often at the forefront of such conflict while they attempt to define and manage requirements. Understanding how to assess a conflict’s root cause and having techniques to defuse volatile situations are crucial to help gain consensus and keep a project moving forward.

· Performance Measurement: Business Analysts can play an important role in reviewing existing solutions or working on the business case for change. Being able to define and implement relevant measures to evaluate individual solutions or an overall organization are key tools that are needed to help keep companies moving forward. Knowing how to leverage methodologies such as Lean and Six Sigma make doing these tasks that much easier.

3. Use Your Skills to Give Back

Many Business Analysts already volunteer their time to causes they believe in, but it may not be in a capacity that leverages their professional skills. Business Analysts can get a lot out of using their skills to give back to others, while at the same time helping their community. Not only is there the satisfaction of helping those in need, but an opportunity to learn how to take the experiences from such efforts and apply them in their organizations of employment. There are opportunities to help organizations who need Business Analysts as well as helping our fellow Business Analysts improve.

Here are some ideas on how to give back:

· Find a local non-profit or charity who could benefit from some business analysis but don’t have the in-house expertise or financial resources to perform the analysis.

· If you like to volunteer in developing countries, speak with the organization you work with to see if you can help them improve their operations or help them with a specific project that requires business analysis. We already have “Doctors without borders” and “Engineers without borders” – why not “Business Analysts without borders”?

· Pay it forward: mentor a less experienced Business Analyst so they can share their knowledge and expertise in the future with others.

· Start a community of practice with other BAs either inside or outside your organization to help improve everyone’s collective maturity and share ideas on how to perform BA activities better.

· Work with your local IIBA chapter to put on an event that will help the BA community grow.

What are your professional goals for 2013? Do you have any audacious goals?

Thoughts on the Agile Extension of the BABOK

Jarett Hailes — Thu, 01 Mar 2012 02:23:00 GMT

Today was the last day people could provide feedback to the IIBA’s Agile Extension of the BABOK. The most recent draft of the document was published in November 2011 for review and comment. The purpose of the extension is to provide readers an understanding of how business analysis can be performed within an Agile environment. Various Agile methodologies such as Scrum, XP and Kanban are presented in high level summaries, and then business analysis activities from the BABOK are mapped to the main events that occur in the general Agile environment. Finally, a list of techniques that can be applied to the BABOK activities in an Agile setting are presented.

Overall the document is well written and does a good job of describing how business analysis fits into an Agile setting. This is a topic that has been much discussed in the past few years, and two years ago I wrote an article that summarized several leading Agile experts’ views on how the Business Analyst role fits into the evolving Agile framework. As Agile methodologies continue to gain traction in corporate software development processes, it makes sense to ensure that Business Analysts feel comfortable with how their skills transition to a different environment.

That said I have a concern about having such an extension does to the perception of business analysis as a profession and to Business Analysts as a role. I do not see business analysis as some activity that is merely a component of software development or IT solution delivery. Business Analysts can play a strategic role in the organization to help ensure that the organization is capitalizing on its opportunities and adapts efficiently to changing market, regulatory and internal cultural changes. When BAs are deployed throughout an organization they can get a hands on sense of what’s working, what’s not, and can draw upon technical and behavioural expertise to find innovative ways to help the organization continually improve its operations. I have had the opportunity with several clients to step outside of IT departments and play such a role, and not only is it personally rewarding but it is also where I have been able to provide the most value.

In many organizations I come into contact with business analysis is perceived as some 'IT thing' done to 'help the techies figure out what the business wants'. This perception often comes found the originations of professional business analysis, and while understandable, it is something that must be challenged in order to unlock the potential of having professional Business Analysts throughout the organization working on problems that are not limited to an IT solution scope.

The second version of the BABOK made great strides towards demonstrating how business analysis can be performed outside of IT and explained why it is needed by organizations to adapt to today's constantly changing environments. While some organizations are starting to see the value of BAs outside of IT, having a document such as the Agile extension reinforces existing preconceptions of business analysis in a limited role. In some ways publishing an Agile extension seems like a mea culpa to the wider business audience, indicating that it is wrong to think of business analysis outside of a software development context. I am sure this is not the intention of the IIBA, but given the stage of development of the profession it may be an unintended consequence.

I have been meeting with several executives, managers of Business Analysts and consulting business development personnel in a study group of the BABOK. Through their reading and discussion of the BABOK’s concepts they have come to recognize the value of the information outside of an IT setting, which has taken some work given that while the BABOK V2 is more generic than before, many of the concepts and examples rely heavily on the IT domain. When I mentioned that there was now an Agile extension, most wondered if in fact we had all been reading too deeply into the BABOK; maybe it was just for IT environments after all.

Perhaps I am being too harsh on having such an extension – after all the Project Management Institute has a construction industry extension to the PMBOK, which is one of the industries that were a main influence in the beginning of the institute, as well as for government. The PMI even has an Agile practitioner certification, which is decidedly focused on software development. Nonetheless, I feel that given the developmental stage of business analysis as a profession, having such an extension sends mixed messages on the applicability of the body of knowledge, and limits the career opportunities for Business Analysts in the near term.

As I mentioned above I think the content is valuable and good for BAs who are working in the IT domain to know, but I believe that some other term may be been better suited to describing the document. Calling it an extension of the BABOK ties it too heavily to the general body of knowledge in my mind. I could have seen this as a valuable ‘industry application guide’ or something along those lines.

What are your thoughts on the Agile extension? Do you like the content? What do you think that such an extension does to the perception of business analysis in general and outside of the IT domain in particular?

6 Traits Of A Great Business Analyst (And How To Interview For Them)

Jarett Hailes — Tue, 19 Oct 2010 02:16:00 GMT

Whether or not you have ever been a Business Analyst yourself, if you work with enough Business Analysts over time you learn what sort of characteristics make a BA successful. Regardless of the Business Analyst’s skills, experience, domain knowledge or certifications, there are inherent traits that will more often than not help a person succeed in accomplishing business analysis tasks.

Over the years I’ve come to recognize most, if not all, of these traits in individuals whom I and many others have recognized as great Business Analysts. These traits are valuable because they help one thrive in a role that often comes with no authority (but lots of responsibility), can have constantly shifting demands and priorities, a lot of environmental ambiguity, and yet is one that plays a key role in the success or failure of projects, initiatives, and even overall organizational performance.

These traits are not meant to determine whether a person is a competent Business Analyst. Competency in business analysis tasks is something that typically is tied to the ability for an individual to perform BA tasks at a certain level of complexity and autonomy. Usually Business Analysts improve their competency over time with experience and ongoing professional learning. That said I find these traits can partially predict a person’s inherent ability to rapidly improve their competency in business analysis through on-the-job and classroom training and experience.

The neat thing about these traits is that you can structure interview questions and scenarios to actually try and bring these traits to the surface. If you look for these traits while you’re interviewing you will definitely have a leg up in determining if the candidate will be able to work well as a BA in your organization. While you will still want to assess the BA based on their skills, experience, etc., I would highly recommend looking into setting up scenarios during your hiring process that will help you establish whether these traits are inherent in the individual or not. I’ve put some suggestions on how to search for these traits during interviews below.

1. They are engaging

Business Analysts need to do something that is inherently tricky; convince people to commit their time and effort to working on activities that often aren’t their top priority. Rarely does a BA have the project with stakeholders who can commit their full time to requirement elicitation and validation, or have an unlimited amount of time to follow the schedules and priorities of their stakeholders and have requirements gathered when it suits them. Business Analysts often learn how to cajole, coerce, beg and otherwise convince stakeholders to help them accomplish their tasks, but the process is a whole lot easier if the Business Analyst is engaging. A great Business Analyst makes you want to work with them, even if you’re the Director of Sales and they need you to help define performance metrics for the CRM database upgrade.

A Business Analyst that can communicate the value of a project with passion and dedication will inherently pull people in without needing to list off the million reasons you need to be involved. Instead, you’ll want to be involved (or at the very least be willing to be involved more than you otherwise would). Having an engaging Business Analyst can bring everyone to the table and help groups focus on achieving meaningful results in a short amount of time.

How to interview for this trait: Look for the most boring looking project or accomplishment on the candidate’s resume and ask them to describe to them how they were able to perform . Ask them a similar question for what looks to be an interesting or exciting project. Listen to how they deliver their responses. If you feel like you want to hear more from the candidate regardless of the project being discussed, then there’s a good chance that the BA knows how to be engaging regardless of the environment.

You can also ask them about how they’ve dealt with situations where stakeholders were not committing sufficient time/effort to accomplishing tasks and how they overcame it. If the first thing out of their mouth was “I talked to the Project Manager” then you probably have someone who does not believe they can inherently engage stakeholders.

2. They aren’t easily ruffled by conflict

Business Analysts are often faced with unruly or disagreeing stakeholders, unrealistic timelines and potential or actual shifts in scope. Sometimes all their hard work that has been put into gathering, validating and presenting requirements turns out to be completely useless as soon as the sponsor sees the report and says “but I thought we were supposed to build X. That’s what I really need, regardless of what the charter says”. Top that off with trying to get stakeholders to return your calls and e-mails, evaluate the relevancy of 200 business rules in the current software, and fighting with the new requirements management tool and it’s a surprise there aren’t more Business Analysts with frayed nerves.

Like Project Managers, I’ve found that great Business Analysts cannot be easily perturbed. They realize that most of their environment is out of their control, and even though they can often be held accountable for things beyond their scope they take as much as possible in stride. Business Analysts have to be able to handle constantly changing goals, priorities and whims of many stakeholders. While they shouldn’t be simply trying to accommodate everyone without question, they need to realize that it’s all part of the process and that inevitably there will be delays or issues that will impact deliverables and timelines.

How to interview for this trait: It is one thing to say “tell me a time when…,” it’s quite another to actually see someone’s reaction when faced with a situation. After a candidate has responded to a behaviour-based question, one of the interviewers can pretend to become rather rigid and start making assertions that the Business Analyst did not do the correct thing (e.g. “I don’t think you should ever contact the sponsor directly, you should always go through the Project Manager”). Have the interviewer continue to insist on their point as the candidate tries to explain their reasoning or position. Don’t get into any unprofessional conversations such as name calling, but be stubborn. If there’s a hint of a defensive response, then that’s a bad sign. If they take it in stride and are able to accept the interviewer’s opinion, then this is a very good indicator. Business Analysts should expect everyone to have an opinion different from them and know when to move the subject along and acknowledge the person’s point of view.

While I don’t think this technique is suitable for every interview process, I think it can yield insightful responses in many circumstances.

3. They are multi-disciplined

A lot of Business Analysts have expertise and experience in IT and their domain. While this could be considered multi-disciplined I am looking for individuals who have experience in performing tasks in completely unrelated fields across multiple industries. I find that Business Analysts are able to more easily relate to capture information, interact with stakeholders and identify opportunities if they’ve worked in many industries, either as a BA or in an operational role. Great Business Analysts can leverage their knowledge of several disciplines to take techniques and information and apply it to their current project or duties. I find Business Analysts who have been in several industries to be more versatile and less susceptible to believing that certain analysis tools, techniques or work products are what are needed for any and every situation. Business Analysts with an academic background that crosses several disciplines (for example, a degree in Sociology but a Master’s or Doctorate in Math) also demonstrates a multi-disciplined mindset and experience.

A great Business Analyst realizes that all their activities and methods need to be adapted to the specific environment and situation at hand. Multi-disciplined Business Analysts can often find innovative ways to deliver value to their projects and organizations with their wide range of knowledge.

How to interview for this trait: Few people stay in the same field for their entire career, so ask the candidate to discuss a time when they’ve applied knowledge from a job in one field and used it in another field (even if it’s what they learned flipping burgers before heading into investment banking). If the candidate has always been in the same field but has an education in a field that is more or less unrelated to business analysis (Arts, Chemistry, Real Estate, etc.), ask them how they feel that education can help them in a specific BA situation (e.g. “What did you learn with your that would help you be able to ensure that you have a complete set of requirements?”).

4. They are inquisitive

I’ve never met a great Business Analyst that didn’t ask more questions than they answered over the course of a project. Great Business Analysts realize that they are merely a conduit of information and are always asking as many stakeholders as needed to help elicit, refine, validate and implement requirements. A Business Analyst should always be thinking “What, why, how, where, when, who” when they’re communicating with stakeholders and analyzing solutions.

Often Business Analysts won’t get the real information they need the first time around. Whether it’s determining the root cause of a problem, identifying the core need, or ensuring that all the bases are covered when reviewing a potential solution, great Business Analysts realize that while they’ll probably never have a complete set of information they can ask timely and relevant questions to get as much information as possible so effective decisions can be made.

How to interview for this trait: Tell the candidate a little about the project or operational role they will be performing, but keep it high level. If they don’t ask any follow up questions, that’s a major red flag. The more questions and follow ups they ask that are pertinent and relevant, the more likely they are naturally inquisitive and know how to search for important details and considerations. (Note: if they start asking questions like “what’s my vacation pay” and “what are the benefits of the company” before asking for a lot of details about the role, you’re probably looking at the wrong person for your job).

5. They think (and action) strategically

Business Analysts need to always be asking questions about the value of their work. Work that doesn’t relate to the strategic goals of the organization doesn’t just have little value, it’s really fake work. Great Business Analysts understand why what they’re doing has value and can articulate that to stakeholders. In addition, they are always looking for ways to uncover value for the organization by thinking about the organization’s strategic goals. This may lead the BA to recommend the merger of two overlapping projects or highlight the opportunity for process re-engineering that will reduce costs. Great Business Analysts show their companies that they are not simply the “IT guys who don’t just talk tech,” but are people who understand the needs and goals of the organization and can find ways to help them realize their objectives more efficiently.

Great Business Analysts also know how to action on strategic thinking. Rarely will the Business Analyst have the authority to act on an opportunity themselves, but they are willing to develop compelling arguments for superiors to take action. Doing so may place them at a slightly higher level of risk (since they may be going against popular or conventional thinking), but they also do this altruistically for the greater good of the company. I’m not advocating that Business Analysts should be mavericks, but they should know how to communicate the value (or lack of value) in recommendations to superiors.

How to interview for this trait: Give the candidate a scenario for a proposed project. Ask them if they believe the project is a good one to undertake given your company’s goals (assuming the BA could have found these goals on your website or in provided materials prior to the interview). Good candidates for any position should review those goals prior to going to a job interview, and a great Business Analyst should know how to measure a project against those goals.

Also ask the candidate if they’ve ever been on a project where they didn’t think the project was that valuable to the company. Start off by asking them something about the project (how was it run, how did they know it wasn’t valuable, etc.). After they’ve done describing the project, ask them what they did to let others know that the project wasn’t valuable. If they didn’t do anything or very little, then this makes me question whether they can really action on strategic thinking.

6. They care about the details

Most of the above traits are things you want to see in other roles, particularly business leaders and salespeople. One of the things in my mind that sets the Business Analyst role apart from some of these other roles is the need for attention to detail. You can’t be an Analyst without being a little bit anal J Great Business Analysts know the importance of having precise and clear details documented and communicated properly, and are adept at managing large amounts of detailed information.

This also means that a Business Analyst must be able to scale their message and thought processes. A great Business Analyst can give a compelling presentation to executives on the value of a project and then turn around and discuss with a Quality Assurance member why a change to requirement R-1938 impacts test cases T-321 and 329. Without proper attention to detail the Business Analyst can’t ensure that the actual solutions developed or procured will meet the needs of the customer, or even that those needs are sufficiently articulated to be able to adopt solutions.

How to interview for this trait: The best indicator of this trait is to review work products that were exclusively developed by the candidate, although this is often difficult to acquire. Instead you can get the candidate to play the equivalent of Where’s Waldo. Ask the candidate to review a sample deliverable and point out potential issues in the content (e.g. imprecise/ambiguous verbiage in requirements, lack of traceability, etc.). Make sure you give them sufficient time to review the document; this is typically a good activity for a 2^nd or 3^rd interview. The more issues that the candidate uncovers the better (bonus points if they spot stuff you didn’t even intend to be an issue).

I would also evaluate how detailed the candidate’s questions are when asking about the job, the work environment, etc. Again great Business Analysts want as much information as possible, particularly when they’re looking to commit to a position that will take up the majority of their waking hours.

Finding Great Business Analysts

Finding great Business Analysts can take time and effort; hopefully these traits will help you identify individuals with the potential to be great BAs even if they’re in different roles or don’t have the experience yet.

What are some traits of great Business Analysts that you have worked with?

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

When the Client Isn't the Customer

Jarett Hailes — Tue, 03 Aug 2010 00:09:00 GMT

Usually when a Business Analyst is working on a project the client (which I’ll define as the party or stakeholder who receives the benefit of the Analyst’s services) and the customer (the party who is paying for the Analyst to render the services) are one in the same, at least from an overall organizational perspective (i.e. the client and customer belong to the same organization). However, there are times when the client and customer are completely separate entities.

This sort of situation can arise in many environments. For instance, the customer may be an association who wants a new software solution that will be used by its members. Other times an entity may be required by law or regulation to provide certain services to other organizations and a project is struck to create a new solution to address these needs. Regardless of the circumstances, having a separate client from the customer can put the Business Analyst in compromising situations, typically due to divergent needs between the customer and the client.

Typically when a Business Analyst faces a situation where various project stakeholders have differing goals, agendas, capabilities or level of engagement in a project, the project’s structure can usually help resolve differences that can’t be worked out through other means. Within most project structures there will be a project sponsor or steering committee that is responsible for final decisions if consensus cannot be met. However, in a multi-organization project the project’s structure may have little to no representation from the client base. This may not be too surprising, particularly if the project was struck based on primarily internal consultations.

Often the Business Analyst is an advocate for those who will use the end result of the project. To become an advocate one needs to empathize with the client base or else it is difficult to communicate the client’s needs to the other project stakeholders. Once the Business Analyst understands the client’s needs they can often want to see those needs become fulfilled by the project.

However, the customer may not have the desire, resources or mandate to meet these needs. If the customer for whatever reason doesn’t believe that some or all of the client’s requirements need to be met and the project structure does not lend itself to providing the client a voice at the decision table, the Business Analyst may find themselves having a hard time accepting the customer’s position.

When the client and customer are not the same entity the Business Analyst ends up in a type of agency problem; they’ve become an agent for the client whose interests do not align for the principal (the customer). The Business Analyst was tasked with eliciting requirements for the client; if the customer in the end chooses to neglect some of these requirements it can be frustrating or disappointing to see the client’s needs going unmet.

Ultimately the Business Analyst will be faced with a choice to decide how far they will go in representing the client’s needs. Since the customer has the ultimate authority on the project the Business Analyst must determine what level of conflict is healthy to ensure that the client’s needs are being met to the best of the customer’s ability given the overall project environment. Obviously the Business Analyst should work within the bounds of professionalism, but there is a question at what point the Business Analyst should acquiesce to the customer’s expectations.

I don’t believe there is a simple solution or answer to this dilemma, and each Business Analyst will need to decide for themselves where the boundary lies if they encounter this situation. Have you ever been in a situation where your role as a Business Analyst put you in conflict with the project sponsors or Steering Committee? How did you deal with the situation?

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Spring Cleaning Your Personal Backlog

Jarett Hailes — Sun, 18 Apr 2010 04:44:00 GMT

As spring begins to plant its roots in the Northern Hemisphere, many people will begin an annual spring cleaning of their home. All the clutter that has accumulated over the past 3, 6, 9, or even 12 months since the last cleaning is collected, assessed and then dealt with (either by moving stuff to a better location, actually using the thing, or throwing it away/selling it).

Like our homes, most of us have a bunch of ‘to do’s’ that build up over time. Whether you are someone who meticulously manages all the tasks that you must do or you are someone who will try and keep all their ongoing duties solely in your head, chances are that you have a list of things that you have wanted or needed to do but have never quite found the time to get around to. I like to call the list of outstanding tasks that someone has to do (whatever their context; personal or work-related) a personal backlog.

While there’s nothing wrong with not crossing off all your tasks (after all, who really has time to do everything they need or want to?); over time you can develop a level of ‘accountability debt’ to yourself. Most active and high-achieving people strive to get as much done as possible, and when they can’t complete everything that everyone has asked of them they usually take it personally, either at a conscious or unconscious level. This could be manifested as internal guilt, frustration, stress or other negative emotions.

As you feel bad about not being able to accomplish everything you start to make more and more mental reminders of all the things that you haven’t been able to do as if this action itself will help get more tasks completed. This action simply clutters up your brain, which has a finite amount of space for keeping track of things. As your personal backlog list continues to grow, you end up crowding out more pertinent or relevant information from your mind. This can lead to feelings of confusion or lack of focus on the tasks at hand that matter the most.

So, if you’re feeling like you have a million things on your mind, it’s time to perform a little spring cleaning. This activity will involve 4 steps as described below.

Collect

Write down everything you can think of that someone has asked you to do or that you’ve pledged to do. Nothing is too big or too trivial to be included in this list. This should span your work and personal lives; don’t forget about promising to clean Aunt Martha’s eaves troughs (you know she won’t). Include problems that you need to solve (for instance, figuring out how to make your sales estimates more accurate going forward or what to do about your son’s late nights) and that you may need some dedicated thinking time to properly ponder.

This may not be something you can do in one session, but allocate some dedicated distraction-free time to this effort. You will be surprised how many little items come bubbling back to the surface once you get on a roll.

If you already have one or more to do/task lists, this is a great place to start. For this activity you will want to consolidate all of your task lists into one big master list. You may be used to segregating certain aspects of your life and find it effective to manage them that way, but from a spring cleaning perspective you will need to look at everything holistically.

Don’t be surprised (or daunted) if this list grows into hundreds of items; instead take satisfaction that you now have a single point of reference for all your outstanding action items. You no longer need to carry these about in your brain’s short-term memory.

Break Down/Up

You will want to review your list for items that are not immediately actionable (that is, there is something that you would first need to do in order to accomplish the stated item). Those items should be moved to a second reference list and be linked in some way to the one item that is currently actionable on the main list.

This way your to do list becomes a series of ‘next action’ steps, not some nebulous list of end goals that may have dozens of steps that need to be performed in order to be accomplished. Having a list for achievable next steps will add value to this list when you’re looking for what you should do next or at a given moment.

Prioritize

Once you have your master list, it’s time to prioritize. The goal of this prioritization is to have a single ordered list from the highest priority item to the least priority item.

Some of you may want to categorize your items into work and life at this point. I personally find that my life is not so easily segregated (and I would suspect that with modern working practices most people’s are not either), so I would suggest you try and come up with a single prioritized list.

Similarly, you may have a desire to have ‘high/medium/low’ or similar buckets and then just place all your tasks into one of the priorities. While this may be a good starting point so you can manage prioritizing elements further, having buckets of items doesn’t help you actually get any of the tasks done later on. When you’re in working mode, you will want to quickly scan the top of the list and see which of the items are actionable at the moment. Having a list of 10-30 ‘high priority’ items doesn’t help you make a decision at that point, and can lead to feeling overwhelmed and helpless right at a time when you could be easily getting started to work on something.

If you need help getting started, associate due dates to the items that jump out at you off the page as stuff that has to be done by a certain time. This should help you figure out where some of the items fit on the list. Others may not have a set due date but still need to be placed higher up the list.

The end product doesn’t have to be perfectly prioritized; you shouldn’t spend more than a few seconds debating whether one item is above or below another. The goal is to have a general order of importance based on your current life situation that can be easily referred to going forward.

Prune

Once you’ve prioritized your list, start scanning the items from top to bottom. After each item ask yourself “do I really need to get this done?” Once you start running into a steady sequence of ‘no’ answers, start looking for a place to cut off the list and remove all the items below it. Then quickly scan the remainder of the items to see if there’s anything you actually do need to do and bring it back to the pruned list (or perhaps add a couple of items to your pruned list for ‘Sorry I can’t do this messages’).

You need to be honest with yourself and look at your available time, your other commitments and obligations and your personal energy levels and goals to figure out where the line should be drawn. But you do need to draw the line somewhere; I haven’t met anyone who is able to accomplish everything that they put down when they’ve done a brain dump.

Ongoing Maintenance

Once you’ve done this activity, you now have an actionable, up to date and realistic list that you can use going forward to take on your tasks and duties. If you use this opportunity to manage this list on an ongoing basis, you will likely find that your mind will be less cluttered and you will be able to easily find tasks that you can do in any given situation (e.g. those 10 minutes between your meetings) by keeping this list up-to-date and close at hand.

Spring cleaning can feel like a chore, but when you do it on your personal backlog the benefits of a clearer mind and the ability to focus easier without worrying about forgetting to do something can be a major energizer for the months ahead.

The Lost Stakeholder Analysis Dimension: Engagement

Jarett Hailes — Fri, 19 Feb 2010 03:13:00 GMT

Stakeholder Analysis is an important and often ongoing activity that Business Analysts perform as part of their duties. Solution delivery team members need to understand who else is involved or impacted by their work effort, how they can interact with these people or groups, and what sort of tradeoffs exist in pleasing one group over another.

The BABOK highlights several important dimensions that can be collected on each stakeholder, namely:

The stakeholder’s attitude towards the project or solution team

The stakeholder’s influence on the project or solution team’s success

The type of stakeholder (internal/external, direct/indirect, etc.)

The body of knowledge also describes artifacts such as a RACI chart and stakeholder map to help manage the information you collect on stakeholders.

In addition to these dimensions, I believe that there is another consideration that needs to be included in stakeholder analysis: the stakeholder’s engagement level with the project or solution team.

A stakeholder’s engagement level describes the expected or actual amount of involvement a stakeholder has with the project. Since the required level of engagement with certain stakeholders may differ over the course of a project, this level should represent the level of engagement relating to activities that could or should involve the given stakeholder. In some cases, you may wish to separately track the expected/needed versus actual amount of engagement.

This is an important dimension to consider for several reasons:

The level of engagement that a stakeholder provides can greatly impact the amount of effort required to perform other Business Analysis activities, including requirements gathering/validation, solution assessment, enterprise analysis, etc.

If you expect to see high levels of active engagement from certain stakeholders who may not be considered high priority in the overall context of the project, you may find that the team will spend a disproportionate amount of time dealing with these stakeholders. By identifying such potential issues up front mitigation strategies can be developed to ensure that efforts are focused on where the highest needs are.

Conversely, if you identify high priority stakeholders with likely or actual low levels of engagement the team can identify potential solutions to address the causes of such disengagement, escalate this issue with the sponsor as needed, or allocate sufficient time to ensure that these stakeholders’ needs are still adequately met.

The Engagement Gradient

Every stakeholder’s level of engagement can vary. I use 4 markers as generic signposts to describe the general level of engagement each stakeholder has.

Proactive: these stakeholders are heavily involved in project activity. They are not only willing and able to answer questions, but they’ll ask you questions you haven’t thought about yet. They want to trial out potential solutions, volunteer for committees and the like. Generally they behave as an active team member rather than a stakeholder.

Responsive: these stakeholders get involved in the process, but only when prompted. They will respond to surveys, join in interviews or workshops, and provide suggestions to outstanding items but they won’t go out of their way to let you know something or volunteer to actively work on issues.

Marginal: these stakeholders will participate on occasion, but not all the time. They will provide limited feedback, give short responses, not really contribute meaningfully to discussions or suggest solutions to problems. Such stakeholders can quite often feel obligated to be involved (although if this is the case it should be documented separately in the attitude section).

Disengaged: these stakeholders you rarely or never hear from. They will not respond to meeting requests, surveys, etc. When they are present it’s virtually impossible to get them off their Blackberries or do anything beyond nod their head (either in agreement or disagreement).

You may find that some stakeholders exhibit various markers depending on the subject or issue at hand within a project. If appropriate you may have a matrix of engagement levels for your stakeholders with the stakeholders and the various aspects of your project representing the axes.

Leveraging Engagement in Stakeholder Analysis and Other Activities

By bringing in the engagement level dimension into your stakeholder analysis, you can now optimize your other Business Analysis activities much more efficiently. Taking this information into consideration in conjunction with the stakeholder’s attitude and influence towards the project can help identify potential risks to the success of the project, find potential bottlenecks in upcoming project activities and look for ways to improve stakeholder communications.

For example, let’s say that you have a stakeholder with a great attitude, is proactively engaged but of low influence to the project? Such a stakeholder could have the potential to take up a lot of the project’s time. Perhaps you can look to leverage their enthusiasm for the project by having them spread the word of the project, get other higher priority stakeholders on board, etc.

When a stakeholder is disengaged there could be several causes. If the stakeholder could pose a major influence on the project I try and determine whether the main reason is lack of time or lack of interest. If it’s the former then we can work on finding ways to involve them in more asynchronous activities or to get them involved at a higher level, if appropriate. If it’s the latter then I know the project may have a potential problem – perhaps the apparent value of the project is not there, or more work needs to be done to ensure this stakeholder sees the value and thus will contribute more to the project.

Looking at the overall engagement of all stakeholders can also give you an idea as to how well your engagement activities are being received. If it looks like most of your stakeholders are not very engaged with the project you may wish to review your communications plan as well as your other stakeholder activities and ask if you have had sufficient input in order to proceed.

It is important for a Business Analyst to acquire and deliver the right information from the right people and organizations within the course of their duties. Stakeholder analysis activities can help a BA navigate the sometimes challenging waters of ensuring that everyone has their voice heard and are sufficiently involved to ensure the project or solution is a success. Understanding the anticipated/desired and actual levels of engagement with stakeholders can help ensure that project goals are met.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Why I Don't Use BPMN

Jarett Hailes — Wed, 10 Feb 2010 01:59:00 GMT

First off, let me just say that I really like the BPMN standard, especially the 2.0 Beta specification. I find the notation to be a powerful and expressive language that takes into account not only the standard elements in business processes but also considers all sorts of interesting possibilities that may arise. I think the new Choreography and Conversation diagrams and additional event types open up new ways to describe intricate processes and collaborations between various individuals and organizations. Indeed, BPMN allows you to graphically model almost any situation that you can find in a business.

And I rarely get to use it.

According to the BPMN 2.0 Beta spec, there are two goals for BPMN. One goal “is to ensure that XML languages designed for the execution of business processes, such as WSBPEL (Web Services Business Process Execution Language), can be visualized with a business-oriented notation.”

The other goal “is to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes.”

While BPMN does extremely well with respect to the first goal, I believe it does not live up to its second goal.

Business People Don’t Get BPMN Right Away

Whenever I stick a non-trivial BPMN model in front of actual business customers, I always get at least some questions. The number of questions varies depending on their sophistication and the number of times they’ve seen a BPMN (or similar) diagram before. BPMN leverages the typical flow-chart diagramming that nearly all business people are familiar with, but they’ve made several changes that make the their models anywhere from slightly confusing to downright unreadable for the layperson.

For instance, one of the most common questions I get is with respect to the fact that each pool has its own start and end processes as well as process flow lines. If there is interaction across the pools then a message flow is used. Most business people get overwhelmed with the additional flow lines and have trouble following the overall process path – usually when a hand off occurs between individuals or organizations you want to follow whoever received the handoff. With BPMN this is not always readily obvious since all pools continue along their own process flows. I could get around this by using only lanes instead of pools since lanes are not considered to be running their own processes, but then I’m not using lanes correctl. Each pool is defined as a “separate business entity or participant” while a lane is used to “separate the activities associated with a specific company function or role.”

BPMN Process Example

Other times people are thrown by the exceptions or compensation processes, since they are usually shown on the same page (although not necessarily). While I personally like these artifacts I often spend more time explaining why they are there than reviewing the accuracy of the actual process itself.

Over time I’ve been able to get some clients used to the notation, but if a new stakeholder is brought in I’m back at square one. To me this shows how BPMN is not ‘readily understandable’ by the vast majority of business people involved.

BPMN is a Great Precursor to BPEL

I definitely see how BPMN is an excellent tool to use if you’re preparing to leverage the Business Process Execution Language (BPEL) and have a BPEL Process Manager solution in place to automate business processes. The BPMN spec indicates that traditional models create “a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes.” BPMN has really been designed to address this gap, but has focused on the technical implementation side by sacrificing out of the box understandability for any given model.

From a solution standpoint this makes sense – if the goal is to in the end have automated business processes then you need to ensure that your model can translate into a language that is computer-ready. BPEL has been around for almost 8 years now and has gained a level of acceptance by software providers and businesses. Combined with the demand for lower labour costs wherever possible and there is clearly a need for non-programmers or extremely technical personnel to be able to leverage a graphical description of processes.

Like any other technically-driven language, BPMN is relatively generic, robust and flexible. In order to achieve its level of flexibility the language must be inherently complex to handle all the possible situations that could fall within the scope of the language’s use. While this is great from an implementation perspective it takes away from the ability for someone with little knowledge about the notation to be able to read a diagram.

When to Stick With the Tried and True Notation

In most situations (performing current state analysis, working through future state processes, validating requirements, etc.) that involve business people interacting with diagrams BPMN is a bit of overkill. When I’m not trying to create an automatable BPEL-driven business process I find that business people can almost universally understand a flowchart. This is something that most individuals have had exposure to at some point, and even if they haven’t there are so few different diagramming objects that it’s easy enough to pick up quickly (at the very least you don’t need a 226 page reference guide to figure out how to understand the chart)

While a flowchart may not be able to elegantly model complex business processes as well as BPMN, you can still get the job done by breaking up complex situations into several smaller component diagrams and then using the link object to move between the components. I find that this not only helps me ensure that each component chart is clear when I’m building the model, it also helps me work through specific sub-processes or exception cases with clients when I’m reviewing the details with them since it’s easier to focus on a single, relatively straightforward chart at a time.

Flowchart with Swimlanes Example

One part of BPMN that I’ve brought over to the flowchart world and use nearly every time is the swimlanes artifact. Having swimlanes helps everyone clearly understand the responsibilities and activities that each participant in the overall process plays, where the hand-offs are and what kind of information is going back and forth. I’ll often attach document or data elements when the flow goes across the lanes to show the details of the hand-off, which embeds a lot of the information you would typically find in a Data Flow Diagram (DFD) for the given business process. In fact, if you wanted you could roll up these messages and create a DFD if you have a need for that type of structured analysis.

While BPMN is a great way to prepare a business process for automation, it may not be the best choice when it comes to interacting with the business itself to document, verify and envision business processes.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Root Cause Analysis: Using the Five Whys

Jarett Hailes — Tue, 26 Jan 2010 00:55:00 GMT

Business Analysts are often thrown into projects to help gather requirements around a known, defined problem. Other times we’re asked to analyze the current state of a certain process, organization, system and look for ways to improve areas that are clearly lacking. I’ve noticed that when we are brought on a project, the problems described are likely only surface symptoms to large issues. For example:

· This system can’t handle more than X transactions per hour and it’s killing our procurement process’ performance

· This organizational unit doesn’t have the right staff to be able to keep up with the demands being placed on them

· This process is obsolete and overlaps with three of our other processes

While it’s great to have a problem identified, it is well worth the effort to ensure that you are analyzing a root cause problem and not only a symptom of a greater issue. If you don’t do this step, you may end up using lots of resources at what amounts to a band-aid solution.

A great technique to help delve into a problem and identify possible root causes is the ‘Five Whys’. When an issue is presented you ask the question ‘why did that issue occur?’ Once you have your answer, ask the question ‘and why is that so?’ Continue until you have asked ‘why?’ at least five times, even if you felt you’ve reached the root cause after 2 or 3 responses.

Joel Spolsky details a good example of how using the Five Whys can elicit solutions to underlying problems. Recently I came across a similar example with a client (certain details have been changed).

Issue: Employees did not receive their pay stubs on pay day.

· Why? Because the printing system failed the day before pay day.

· Why? Because the system could not recover from a hardware fault.

· Why? Because the system uses outdated hardware that has no automatic redundant backup.

· Why? Because the system hasn’t been replaced as it hasn’t been identified as a high enough priority to allocate budget to its replacement in the current economic climate.

· Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.

Some people may have been tempted to stop after the third or fourth question. We could have rushed to find a way to set up either an automatic failover system or to increase the availability of resources to replace legacy hardware in the event of a failure. Or we could have determined that the system needs to be replaced and develop a business case to do so. But the overall challenge that faces the organization is a way to assess the relative risks of failure for all enterprise applications and come up with mitigation strategies in light of the available funds to maintain and replace systems going forward and to holistically evaluate the replacement of such systems over time.

It may still be a good idea to address the symptoms found during this activity. In the end the root cause(s) that you identify may be deemed to be outside of the domain of you and/or your project team’s responsibility. The key is to recognize that there are potentially larger issues that may need to be addressed; otherwise this issue may resurface with different symptoms in the future and to pass along this information to those who can act on it.

The Five Whys isn’t the only tool you may want to use to help identify potential root causes (here are some suggestions on how to improve its efficacy at finding root causes), but I believe that it can be used to quickly assess whether a problem that has already been defined may in fact be a symptom of greater hidden issues.

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com

Mitigating the Risk of Story Point Drift

Jarett Hailes — Mon, 18 Jan 2010 01:38:00 GMT

In many Agile projects requirements are not typically written in the form of a formal requirements document. Instead, a collection of concise but effective means of describing what must be built called user stories are often used. User stories describe the behaviour, performance, or interface of a system from a customer’s perspective. A typical user story might look something like this:

As a potential customer I want to be able to view books based on the search criteria I entered.

User stories are not only effective requirements management artifacts, they are also essential to estimate the scope/size of the project and to track the progress of the team. When determining the size of the project, teams estimate the level of effort required to complete each user story and then aggregate their results to come up with their estimate for the scope of the project (for more details on how to estimate level of effort in Agile projects, see Mike Cohn’s excellent book on the subject).

Agile teams will often use a unit-free type of measure called story points. The advantage of using story points is that their inherent value is relative. Instead of trying to come up with absolute values typically related to time (for instance, how many days will it take to complete feature X), story points are only concerned about the relative effort or complexity of a story compared to the other stories that have been or need to be completed. When the total number of story points for the project is combined with a team’s velocity (the number of story points completed per iteration period) project stakeholders are able to get an increasingly accurate picture of the size of the project and the time it will take to complete given the current team.

Initially when the team forms they will estimate story points for some number of baseline stories. For instance, the team may have the following 3 stories as their baseline:

As a user I want to browse the book collection by subject: 8 points

As a user I want to be able to save my payment information: 2 points

As a user I want to be able to recommend my favorite books to people: 5 points

From this baseline other user stories are estimated in terms of their perceived relative amount of effort to accomplish. For larger projects, most user stories are estimated as epics, larger user stories that will be broken down later on in order to actually tackle development.

Over time, new user stories will be added to the product backlog, others removed and some will be altered to reflect changing requirements. All the stories that are added or changed to the backlog will require story point estimation.

One of the potential risks that exists when using story points is what I call ‘story point drift’. Story point drift is when user stories that had a given story point value at the beginning of the project require substantially more or less effort than stories with the same story point value later on in the project for the given amount of effort required to complete a story.

For instance, let’s say I have the following user stories estimated later in the project:

As a user I want to be able to have my bank account linked to my login and set up a monthly withdrawal plan: 8 points

As a user I want to have a theme editor that can customize the look and feel of my online affiliate store: 5 points

While the above user stories may accurately represent their relative size compared to each other, in comparison to the stories that were estimated at the onset of the project it appears as though the latter group’s story points under-represent their complexity and level of effort required. I would suspect that the amount of work to enable automatic bank transactions is substantially larger than the amount of effort required to build a browse by subject feature.

I find the risk of story point drift increases on larger or longer-term Agile projects. Story point drift can occur for several reasons:

The team’s collective memory is short term: when a team begins estimating new stories, they typically draw upon their experiences from recently completed stories. If some of those stories were misclassified (either required materially more or less relative effort than was represented in the story point estimate), then the team can end up believing that these recent stories are the new norm for the value of the story points and use these as references going forward, which skew the story point values from the original baseline references.

The team’s complement has changed: it is not uncommon for project teams to change over time. I’ve noticed that even as teams get larger or smaller that a team’s velocity can appear to remain constant. When investigating this, I’ve found that it’s often because the team begins to estimate stories with fewer points, since they now feel that the story is ‘easier’ since there are more people to work on the project. As a result stories that might have been considered 8 points previously are now being estimated as 5 points. As a result, despite the fact that the team is likely getting more done given their drift in estimates the team’s velocity appears unchanged.

Baselines are not referred to: Agile projects usually thrive by the minimization of overhead that does not lead to customer value and by adapting to non-ideal situations. For example, Agile teams rarely wait for everyone to show up for a meeting – the meeting is time-boxed and starts and ends on time regardless of who is missing. However, at times Agile teams may forget to bring physical objects like their reference stories to meetings. Sometimes teams will try and get through the meeting based on recollection rather than actual reference. Without the actual reference stories and point values in hand, the resulting estimates can be somewhat skewed.

When I’ve seen story point drift it has occurred in small increments over time – you don’t realize that there’s been a dramatic deviation in the estimates until sometimes months later. Story point drift can cause issues with resource planning and progress and time to completion estimation. Here are a couple of strategies I’ve used to help mitigate story point drift:

Bring mixture of original and recent stories as the baseline for new estimation: it never hurts to hold up your original estimates when doing relative comparisons. Having some recent examples are also helpful, in particular since your initial estimates were likely only for a few potential story point values. Having 1 or 2 stories for each possible story point value can also be helpful when discussing what level of estimate to assign to a new story, or when individuals are deadlocked in a session of planning poker.

Know when certain stories should be re-estimated after implementation: once in awhile you will encounter a story that was a lot more (or less) effort than you initially thought. If the level of effort was sufficiently different from another story that was given the same amount of points, you may want to re-estimate the story so that it does not affect your team’s perception of the value of a certain number of story points. I typically would only re-estimate a story once a project has been going for several Sprints – early on you may discover that many of your stories take less or more effort than you thought and you’ll be tempted to resize those stories. However, as long as the stories are taking about the same amount of relative effort, then there’s no need to re-estimate. So if you thought your 3 point stories would take a day to complete but they’re taking the better part of a week, check to see how your 5 and 8 point stories are taking. If those are also taking a fair bit longer than anticipated, then don’t re-estimate.

Spend a little time every few Sprints and analyze relative stories: the ScrumMaster or Project Manager can review some of the completed stories over time to look for possible story point drift. If some drift is detected, bring it up with the team and see what they think. If the team agrees, then re-estimate the stories that appear to be out of what in terms of relative effort.

User stories and story points can be a very good way to manage the requirements and estimation for a project. Keeping an eye on story point drift will ensure that the team has a good handle on the project’s rate of progress and estimated time to completion. With diligence this method of project estimation can be a very accurate and effective tool for Agile teams.

-------

Jarett Hailes
Larimar Consulting Inc.
http://www.larimarconsulting.com